home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / June 96 / Re Coercion Woes < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  3.6 KB  |  [TEXT/ttxt]
  1. Subject:     Re:Coercion Woes
  2. Sent:        6/24/96 10:24 AM
  3. Received:    6/24/96 10:45 AM
  4. From:        Greg Friedman, friedman@cognosis.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. At 12:09 AM 6/24/96, Hutchings Software Development wrote:
  9.  
  10. > OK, so I installed my own coercion function using FW_CSemanticInterface.
  11. > Then, within my code, I call:
  12. >
  13. >         result_desc.CoerceInPlace(kClass_RIPoint);
  14. >
  15. > where result_desc is a FW_CDesc representing a perfectly good descriptor
  16. > obtained from ::OSACoerceToDesc (I've walked through that code and know it
  17. > works), and kClass_RIPoint is an AppleScript class defined in my 'aete'.
  18. >
  19. > Problem is, my coercion handler does not get called. So, I stepped through
  20. > the debug version of OpenDoc 1.0.4 into
  21. > ODMessageInterface::HandleAllCoercionsAux, where I found the line:
  22. >
  23. >         ODPart* contextPart = _fNameResolver->GetCurrentContextPart(ev);
  24. >
  25. > And sure enough, context_part == kODNULL after stepping over it.
  26. > Unfortunately, there are no public methods for setting the current context
  27. > part.
  28.  
  29. I suspect you may be the first OpenDoc user to attept to invoke a custom
  30. coercion handler after object resolution. I can believe that this hasn't
  31. been tested, and may not work. Unfortunately, the OpenDoc fix might not be
  32. trivial. The problem is that the message interface can be invoked at any
  33. time by a part, and the message interface doesn't have any way of knowing
  34. what the current context should be.
  35.  
  36. > So, I guess there are two problems/questions here...
  37. >
  38. > (1)     Should OpenDoc provide support for parts which want to use the
  39. >         Apple Event Manager to do coersions when the part is not involved
  40. >         in OSL protocol?
  41.  
  42. I'd like to say "yes", but I'm not sure it's possible without some
  43. significant modifications.
  44.  
  45. >
  46. > (2)     With ODF, should FW_CDesc::CoerceInPlace optionally take a
  47. >         FW_CSemanticInterface parameter so in-part coercions can be
  48. >         dispatched directly? Or should I just be calling my coercion
  49. >         proc directly (which actually looks like a good idea now that
  50. >         I've typed up my problem!)?
  51.  
  52. This is the right idea, but it breaks encapsulation significantly.
  53. Currently, FW_CDesc has no knowledge of parts or semantic interfaces. It's
  54. going to stay that way. At some point, I want to push FW_CDesc down into
  55. the OS layer where it belongs. It shouldn't be in the framework layer. For
  56. this to happen, FW_CDesc can't be dependent on parts or semantic
  57. interfaces.
  58.  
  59. If we were developing applications, I would rearchitect things so that
  60. FW_CDesc owned coercion handlers. This would probably be implemented as a
  61. singleton. The problem is that singletons don't work in the OpenDoc world,
  62. because they require part-specific globals (not editor-specific globals).
  63.  
  64. I'll think about this, and come up with a solution that works.
  65.  
  66. In the meantime, you might want to call your semantic interface's coercion
  67. method directly.
  68.  
  69. BTW: Why are you declaring a new "point" class, and not using the point
  70. class defined in the AppleEvent Registry? In addition to the coercion
  71. problem you are having now, you're going to have a problem with comparison
  72. operators during the resolution of whose clauses. Currently, there is no
  73. way to extend the set of comparison handlers invoked by FW_CDesc. The
  74. architectural problem is the same as the problem that exists for coercion
  75. handlers. When possible, you should really use the AppleEvent Registry
  76. classes, since they are supported by AppleScript and by ODF.
  77.  
  78. gsf.
  79.  
  80.  
  81. _________________________________________________________
  82. Greg Friedman      ODF Engineering       Apple Computer
  83.  
  84.